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(C) OXF Data Standardization Requirements 
for 

Interactive Tools 
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Microsoft Windows-Based Personal Computers and Servers 
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29 April 2013 


(C) The OXF Data Standardization Requirements document applies to all new or existing interactive tools 
that are being upgraded. This standard will encourage consistency across the interactive tool environment and 
allow for predictable data output and ingestion parameters. This standard was written specifically for Microsoft 
Windows-based personal computer and server targets. 

(U//FOUO) While this document specifically applies to interactive tools, nothing precludes the use of 
relevant parts of this standard with other target collections/tool development efforts including automated 
operations/tools. 

1.0 (U) Background 

(C) Data delivery to ECG data repository and analytical systems has been inconsistent in format and 
content across COG/NOD elements. Many data deliveries require manual parsing by officers in ECG, or other 
recipients, to enable successful processing by analytical systems. This manual parsing delays information delivery to 
targeters and analyst. Inconsistent content can mean that FI data cannot be acted upon due to incomplete 
information. 

(C) This document will establish a standard format and content delivery of FI data collected via COG/NOD 
interactive tool capabilities. This includes the establishment of baseline requirements for the collection of meta- 
data required for the ECG analytical systems. Often overlooked, it is the metadata that makes FI data collections 
useful to end users. 
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2.0 (U) Overview 

(C) All data collected will be forwarded using the appropriate OXF data schema plus DNT payload schema. 
This approach is a simplification of the NSA's Common Cryptologic Data Format (CCDF). The OXF data schema was 
created by the IOC. Simply stated, each file collected from target will have a corresponding "meta-data” file. This 
file will include the meta data elements as defined in section 4.0 - Operational XML Format (OXF). The data 
collected should be stored in a pre-defined DNT payload schema or as a binary (copy from target). 

(U//FOUO) Data pulls from a target will be collected and stored per NOD standard operating procedures. 

Metadata files (OXF) must be stored in the same directory as the collected data file. 

(U) All generated output such as log or survey data, should be UTF-8 encoded. All generated XML files 
should adhere to XML standards and also be UTF-8 encoded. 

(C) When complete, an operator (or the tool) archives the collection and forwards the archive to the 
appropriate upload directory on the One Way Transfer system for passing to ECG or other means necessary to 
deliver to mission partners (e. g. Mailorder to the NSA). Archives should be created using RAR, ZIP, or other utility 
that provides full UTF-8 support. 

(U//FOUO) Special Note: This standard and associated schemas and examples are to be treated as 
classified - CONFIDENTIAL. Data processing for compliance with this standard must occur on system approved for 
the processing of information at the CONFIDENTIAL or higher level. The metadata required to be collected to meet 
this standard is unclassified when not directly associated with the USG. This means that non-cleared parties may be 
provided - as appropriate - with a list of the metadata required but only cleared resources may be used to develop 
back end processors that parse the data collections into the appropriate payload and metadata schemas. 

3.0 (U) References 

3.1 (U//FOUO) OXF Payload Schema specifications Version 1.0 

3.2 (U//FOUO) OXF Example Set 

4.0 (U//FOUO) Operational XML Format (OXF) 

(U//FOUO) The OXF defines the metadata and associated output files a tool is required to record when 
conducting an interactive operation. The tool shall record, in the OXF standard, metadata of all downloaded files. 
This metadata consists of the following fields at a minimum: 
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Table 1 - (C) OXF Format Fields 


Field 

Description 

If Not Available 

Format 

Notes 

OXF Version 

OXF standard version used. 

Not a valid 

condition. 

String. 

This may be used by 

ECG’s parser to 

determine correct 

parser use. 

UID 

Unique Identifier (UID) 

associated with the machine 

the file or data was collected 
from. This is a generated 

value. 

Not a valid 

condition. 

32 byte String. 

ASCII 0-9, A-F only. 

The specification for 
the generation of a UID 
is captured in 
appendices A - 

Microsoft Windows UID 

Creation Guide. 

The specification for 
the generation of a UID 
is captured in 
appendices A - 

Microsoft Windows UID 

Creation Guide. 

All values used to 

compute this hash will 

also be returned. 

NetBIOS 

Hostname 

Used in the UID computation. 

Leave blank 

String 


MAC 

Used in the UID computation. 

n/a - one MAC 

must be available 

String, colon separated. 
Example: 

58:b6:ff:3E:77:ab 

Collect all Ethernet (to 
include 802.11 wireless) 
or Token Ring MACs, 
order in ascending 

order 

UID Version 

UID version used. 

Not a valid 

condition. 

String. 


File Name 

The name of the file (e.g. 
myfile.doc) 

Not a valid 

condition. 

String. 


File Path 

Full path to the file as viewed 
from the target machine (e.g. 
C:\Documents and 
Settings\John\). 

Not a valid 

condition. 

String. 

NT path format will be 
supported. Logical 
volume path is 
preferred. Note: this 
is only required for files 
copied from the target. 

Create Date 

Creation date of the file. 

Not a valid 

condition. 

YYYY-MM-DDTHH:MM:SSZ 

All times recorded are 

in UTC (a.k.a. Zulu) of 
the attack platform’s 

current date time. 

Accessed Date 

Last accessed date of the file 

Not a valid 

condition for a file 

collected. 

For a derived file, 

leave blank. 

YYYY-M M-DDTHH: M M:SSZ 

All times recorded are 

in UTC (a.k.a. Zulu) of 
the attack platform’s 

current date time. 

Modified Date 

Last modified date of the file 

Not a valid 

YYYY-MM-DDTHH:MM:SSZ 

All times recorded are 
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Field 

Description 

If Not Available 

Format 

Notes 



condition for a file 

collected. 

For a derived file, 

leave blank. 


in UTC (a.k.a. Zulu) of 
the attack platform’s 

current date time. 

Collected Date 

Date/time information from the 

target relative to GMT 

Not a valid 

condition. 

e- g- 

Target Local Date/Time: 

YYYY-MM-DDTHH:MM:SS 

Target offset from GMT: 

+-HH:MM 

Local (ICON) GMT Time 
as calculated from local 
Date/Time plus offset: 

YYYY-MM-DDTHH:MM:SSZ 

This is a combination of 

three elements; two 
from target perspective 

and one based on client 

(ICON workstation) 

date/time information. 

File Size 

The size in bytes of the file. 

Not a valid 

condition. 

String. ASCII 0-9 only. 

No separators 

Tool ID 

A unique identifier associated 

This is an optional 

ASCII characters a-z, z- 

This optional field is 


with the tool and version used 

to collect the data. 

field. 

Z, 0-9 only. 

being included for 
strategic reasons but 
may be used by tools 
that currently generate 
unique IDs associated 

with a tool and version. 

MD5 Hash 

An MD5 of the file. 

Not a valid 

condition. 

32 byte String. 

ASCII 0-9, A-F only. 


Derived 

Derived field will be "true” or 

"false" to indicate whether or 

not the file retrieved was a 

complete copy of a file from the 
target or a file generated from 
data derived on the target. 

Not a valid 

condition. 

“true” or "false” 

Strings exclusive of the 
quotes. 

If a document is 

downloaded from the 
target’s "My 

Documents" folder, the 
derived flag will be set 
to “false.” If one 

executes a “pwdump” 
from the target 
machine, the derived 
flag will be set to “true” 

because the resultant 

file is derived data and 

not an actual file 

created by the target. 

The derived indicator 

should also be used for 
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Field 

Description 

If Not Available 

Format 

Notes 





"partial” files. 


5.0 (U//FOUO) Collected File Naming Scheme 

(U) The metadata file will be named the same as the file forwarded with the addition of .oxf.xml appended to the 
name. The metadata file for a named mvfile.doc would be mvfile.doc.oxf.xml 

(U//FOUO) Files collected from target will be saved to their original name. If multiple files of the same name are 
collected, each will be appended with a sequential number using an underscore followed by the number. Derived 
tiles such as surveys, dirwalks, screenshots, etc.; shall be named according to existing NOD standards. The 
associated metadata tile will carry the same name plus .oxf.xml. Example: 

File Associated Metadata File 

mytile.doc mytile.doc. oxf.xml 

mytile_l.doc mytile_l.doc. oxf.xml 

mytile_2.doc mytile_2.doc. oxf.xml 

ta rget I D_d i rwa I k_20 120530 1348Z.xm I targetlD_dirwalk_201205301348Z.xml.oxf.xml 

(U//FOUO) Actual naming conventions used shall be as specified by NOD standards. Collected tiles and their 
associated metadata tiles shall be stored in the same directory. 
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Appendix A 

(U) UID Generation for Microsoft Windows Devices 

Version 1.0 


Synopsis: 

(C) It is important to IOC’s analytical processes to uniquely identify a machine per target or operation. The desire 
is to compute the same UID for a device independent of which tool generates the UID. This allows IOC to tie data 
sets from different tools to the same (or different) devices. 

(U//FOUO) This standard will used wahen computing a UID for Microsoft Windows personal computers and/or 
servers. 


Order 

Field 

If Not Available 

Format 

Notes 

1 

NetBIOS Hostname 

Use 8 null characters 


Used for computation 

purposes 

2 

MAC 

n/a - one MAC must be 

available 

Hex, example: 

58b6ff3E77ab 

Collect all Ethernet (to 
include 802.11 wireless) 
or Token Ring MACs. 

Order in ascending order. 

Use the first MAC only 
for UID computation. 


(U) UID Computation for Microsoft Windows Based Personal Computers/Servers 

(U) A unique identifier will be generated from the fields listed above by passing each data element into the MD5 
algorithm sequentially in the order described in the table above. 
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